-
Notifications
You must be signed in to change notification settings - Fork 233
SDP-1933: Add SDP Overview Page #2149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
docusaurus.config.ts
Outdated
| trailingSlash: false, | ||
| onBrokenAnchors: "ignore", | ||
| onBrokenLinks: "throw", | ||
| onBrokenMarkdownLinks: "throw", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docusaurus 3 dropped markdown.hooks.onBrokenMarkdownLinks, so we move that setting to the supported top-level onBrokenMarkdownLinks: "throw" to stop yarn start from failing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you might be looking at it the wrong way around. v3.9 marked siteConfig.onBrokenMarkdownLinks as deprecated, and the warnings are saying to instead use siteConfig.markdown.hooks.onBrokenMarkdownLinks. We updated to the latest docusaurus recently, so you might need to do a yarn install?
Source: https://docusaurus.io/docs/api/docusaurus-config#onBrokenMarkdownLinks
|
Preview is available here: |
ElliotFriend
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lookin' pretty good! one quibble with the config changes, but otherwise looks great!
docusaurus.config.ts
Outdated
| trailingSlash: false, | ||
| onBrokenAnchors: "ignore", | ||
| onBrokenLinks: "throw", | ||
| onBrokenMarkdownLinks: "throw", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you might be looking at it the wrong way around. v3.9 marked siteConfig.onBrokenMarkdownLinks as deprecated, and the warnings are saying to instead use siteConfig.markdown.hooks.onBrokenMarkdownLinks. We updated to the latest docusaurus recently, so you might need to do a yarn install?
Source: https://docusaurus.io/docs/api/docusaurus-config#onBrokenMarkdownLinks
| ## What is SDP? | ||
|
|
||
| The Stellar Disbursement Platform (SDP) is an orchestration layer for sending bulk payments over the Stellar network, combining operator-facing dashboards with APIs that cover onboarding, compliance, and funds delivery. It removes the friction of high-volume disbursements—recipient messaging, wallet registration, treasury controls, and Stellar transaction submission—so organizations can stand up programs quickly. SDP is built for NGOs, fintech platforms, payroll teams, and marketplaces that need predictable, traceable payouts without building Stellar plumbing themselves. | ||
|
|
||
| ## When to Use SDP | ||
|
|
||
| SDP is the right fit when you need: | ||
|
|
||
| - **Humanitarian aid / cash assistance:** Register recipients with OTP-secured flows, send invite messages over SMS or WhatsApp, and push scheduled disbursements as soon as wallets are verified (while still handling admin notifications over email). | ||
| - **Payroll or stipend programs:** Enforce MFA and reCAPTCHA for admins, expose Prometheus metrics for reliability teams, and keep treasury funds in a managed hot wallet while still settling quickly on Stellar. | ||
| - **Merchant, gig, or platform payouts:** Use the Admin/Dashboard APIs plus native SEP-10/SEP-24 flows so funds land in trusted anchors, connect to custody or off-ramps, and deliver global payouts through a single control plane. | ||
|
|
||
| ## What SDP Does Well | ||
|
|
||
| - High-volume batch payments with queueing, schedulers, and automated submission to Stellar ledgers. | ||
| - Compliance-friendly flows (MFA, reCAPTCHA, SEP-10 auth, SEP-24 interactive deposits, trusted wallets). | ||
| - Fast settlement via Stellar with real-time monitoring from the Transaction Submission Service. | ||
| - Integrations across custody, wallets, and fiat ramps with configurable messaging channels. | ||
| - Clear Admin/Dashboard APIs and Prometheus metrics for observability. | ||
| - Works globally with multi-tenant isolation via tenant-specific schemas and tunable resource limits per deployment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sorta reads like marketing more than docs. There are a few terms here, like "orchestration layer", "compliance", "fund delivery", that don't map to concrete features in the codebase.
The "When to use SDP" part also doesn't feel use-case specific. Things like the dashboard, Prometheus metrics, reCAPTCHA don't really enable humanitarian aid vs payroll vs payouts, and SEP-10/24 aren't really differentiators either.
I think we can combine this into a single section that just explicitly states what SDP does today and what it does not do.
|
|
||
| - Environment- or tenant-level controls for MFA, reCAPTCHA, and wallet policies, with guidance on hot vs. cold treasury wallets. | ||
| - Multi-tenant mode with isolated admin, TSS, and tenant schemas inside Postgres plus per-tenant configuration. | ||
| - Helm, Docker Compose, and CLI tooling for reproducible deployments and migrations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might fit better in the operational section.
|
|
||
| ### Enterprise | ||
|
|
||
| - Environment- or tenant-level controls for MFA, reCAPTCHA, and wallet policies, with guidance on hot vs. cold treasury wallets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with guidance on hot vs. cold treasury wallets
Not sure what this means.
| ## Architecture at a High Level | ||
|
|
||
| - **SDP Orchestrator:** Core services plus the Transaction Submission Service manage recipient onboarding, messaging, scheduling, and Stellar transaction lifecycles. | ||
| - **Treasury Account:** Organizations fund payouts from a controlled hot wallet, with policies to move excess funds to cold custody. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with policies to move excess funds to cold custody
What policies?
| - **User & Trusted Wallets:** Recipient's wallet to receive funds and initiate local off-ramp journeys. | ||
| - **On/Off-Ramps & Stellar:** Anchors, custody providers, or fiat ramps bridge SDP-managed payouts to local rails while Stellar provides fast, low-cost settlement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can combine these.
| participant Ramp as On / Off-Ramp | ||
| Org->>Treasury: Fund treasury account with Stellar asset | ||
| Org->>SDP: Upload recipients & schedule disbursement |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disbursements aren't really scheduled since the user cannot pick when they happen.
|
Preview is available here: |
As title.